PostgreSQL 12 is the minimum version supported by Django 4.2. Since PostgreSQL 10 the version number is incremented by 1 every time, so I have updated the package names with the really available ones in the Debian/Ubuntu repositories.
PS. there is no postgresql-x-postgis-2.x package.

This is a cleanup in docs that can be backported. Please submit a separate PR with this change.

I submitted the PR #16385

Is this line correct?

I'm doing something weird - using Django's connection params in a non-Django settings (I know it's not recommended, all warranty is off, regular Django not affected). The program's timezone is different from the DB timezone. This line causes the time to be read incorrectly, because it transforms e.g. 2023-04-09 19:44:32.768813+03:00 to 2023-04-09 19:44:32.768813+00:00, which is a different time.

I wonder if this is what was really meant, or if this wants to be res.astimezone(tzinfo=self.timezone) (with special handling of None)? That would result in 2023-04-09 16:44:32.768813+00:00.

Or maybe this assumes the DB timezone == app timezone? But in that case, why is this needed at all?

Replacing with return res or return res.astimezone(self.timezone) causes many tests to fails, e.g. in queries or postgres_tests.test_ranges.

Or maybe this assumes the DB timezone == app timezone? But in that case, why is this needed at all?

As far as I'm aware, this is needed because datetimes are loaded without a timezone so we have to set it manually 🤔

Replacing with return res or return res.astimezone(self.timezone) causes many tests to fails, e.g. in queries or postgres_tests.test_ranges.

Thanks for checking, I'll try it myself and investigate more.
If you're OK with trying a little tweak, that would save me some effort setting up Django dev env. The docstring says "The timezone can be None too, in which case it will be chopped.", so I think it should be something like this:

res = super().load(data)
if self.timezone is None:
    # USE_TZ=False, convert to system local time zone and make naive.
    return res.astimezone(None).replace(tzinfo=None)
else:
    # USE_TZ=True, convert to configured timezone.
    return res.astimezone(self.timezone)

As far as I'm aware, this is needed because datetimes are loaded without a timezone so we have to set it manually thinking

As far as I can see, psycopg's TimestamptzLoader (the super class) always returns an aware datetime in the DB (connection) timezone.

Overall, looking at 4.1.x code, I don't see any messing with timezones other than setting the DB connection's timezone, so I'll try to understand why it's needed in psycopg3 in the first place.

Overall, looking at 4.1.x code, I don't see any messing with timezones other than setting the DB connection's timezone, so I'll try to understand why it's needed in psycopg3 in the first place.

This is probably required in the Django test suite because we're changing the TIME_ZONE setting.

Looked into it, if anyone's interested (TL;DR - it's fine).

I believe the TimestamptzLoader is meant to replace this code in psycopg2 backend create_cursor:

def create_cursor(self, name=None):
    ... snipped ...
    cursor.tzinfo_factory = self.tzinfo_factory if settings.USE_TZ else None
    return cursor

def tzinfo_factory(self, offset):                                           
    return self.timezone

In psycopg2 the tzinfo_factory line has this effect when loading a timestamptz (see code):

1. If USE_TZ = False, returns a naive datetime in DB connection timezone - equivalent to reading aware datetime from DB and doing replace(tzinfo=None).
2. If USE_TZ = True, returns an aware datetime in DB connection timezone and replaces its timezone to Django DB timezone - equivalent to doing replace(tzinfo=self.timezone).

i.e. same as TimestamptzLoader's res.replace(tzinfo=self.timezone) code.

So this indeed relies on the assumption that Django DB timezone == connection timezone, which Django ensures when setting up a new connection.

I think that once psycopg2 support is dropped, this assumption could be dropped, making things less dangerous. But until then, it's better to keep the psycopg2 and 3 behaviors the same.